REMARKS 



The examiner is thanked for granting Applicant's representative a personal interview on 
November 25, 2008 to discuss the pending claims and the cited references. 

Rejections under 35 USC §112 

Claims 1-20 have been rejected in that the limitation "to operate independently . . ." is not 
supported in the specification. This limitation has been removed from the independent claims. 

Claims 11-20 have been rejected in that the limitation "enabling" is unclear. This 
limitation has been removed from claim 1 1 . 

Rejection under 35 USC §101 

Claims 1-10 have been rejected because they are not directed to statutory subject matter. 
As pointed out in In re Bilski, "A claimed process is surely patent-eligible under §101 if: (1) it is 
tied to a particular machine or apparatus, or (2) it transforms a particular article into a different 
state or thing" (Bilski, II. A.). Applicant submits that the method of claim 1 is not only tied to a 
particular computer, but also is transforming information into a different state. 

Claim 1 requires automating personalization of smart cards by executing a 
personalization assistant software tool, generating queries, receiving answers, and finally 
generating a personalization data file using information from the user. Quite clearly, this 
software is running on a computer, for example, web host 316 of Figure 3; a computer is also 
shown in Figures 6 and 7. Thus, the claim is tied to a machine. 

Claim 1 is also transforming the information received from the user into a different form 
that may be used to personalize a batch of smart cards. The software tool provides questions to 
the user and the user answers these questions which are input to the tool. These responses are 
then matched to output data values which are in turn used to generate a personalization data file. 
The personalization data file has thus been created from all of the received information and is in 
a form is suitable for personalizing smart cards. Therefore, answers to questions from a user — 
which normally cannot be used to personalize a smart card — are transformed into a file that can 
personalize a smart card. This method involves a real- world interaction with a person using a 
computer and the creation of a computer data file. Claim 1 is not drawn to an abstract concept, 
an algorithm, a series of mental steps, or a law of nature 
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Further, as required by Bilski at III. B., the transformation must be central to the purpose 
of the claimed process. The purpose of claim 1 is to automate personalization of smart cards and 
the transformation directly addresses that purpose by creating a personalization data file that is 
suitable for personalizing smart cards. 

For all these reasons, it is requested that rejection under §101 be withdrawn. 

Rejection under 35 USC §103 

Claims 1-20 are rejected under 35 U.S.C. §103 as being unpatentable over Tushie et ah 
(U.S. Pat. No. 6,014,748) in view of Harms et al (U.S Pat. No. 6,070,147), and further in view 
of Anderson et al (U.S. Pat. No. 5,884,289). 

Claims 1 and 1 1 have been amended to further clarify the limitation of a smart card 
feature and the process of generating a personalization data file, the file used to personalize a 
batch of smart cards. An overview of the methods recited in both claims may be described as 
follows: running a personalization tool on a host computer in order to ask a card issuer questions 
about the issuer's business and risk management requirements with respect to smart card usage, 
using the answers to obtain specific output data, and preparing a personalization data file based 
on the specific output data. The personalization data file — created by asking questions of the 
card issuer and evaluating the responses — may then be used to personalize the actual smart 
cards, as in claim 11. 

Claims 1 and 11 have been amended to clarify a "smart card feature" and its role in 
generating a personalization data file. The claims now recite that " a smart card feature is a 
parameter representing an issuer business requirement dictating smart card usage ." Support may 
be found at pages 5 and 6 of the specification: 

The personalization assistant guides issuers through the decision-making process 
of selecting their desired debit/credit options. Issuers are requested to respond to 
a series of business questions. Responses to these questions will be used by the 
tool to generate a set of debit/credit parameters and values, representing the 
issuer's business and risk requirements for the debit/credit application. . . . The 
actual mechanics of capturing the data to be used. . .will be transparent to the 
Issuer who is then free to focus on the business/risk management aspects of this 
process. 
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Other sections of the specification also support the description of "smart card features" as now 
recited in the claims. For example, Figures 16 and 17 describe various business requirements 
and the screen shot in Figure 16 provides: "In addition, you can support optional features based 
on your market requirements." Page 14 (describing Figure 8) states: "... responses to a 
plurality of queries form business decisions 804, which are provided as input to the 
personalization assistant 320." In another example, page 31 of the specification states that "the 
invention provides a user friendly tool that is able to take business related answers to generate 
technical settings . . . without requiring the understanding of the technical settings." 

A smart card feature is a parameter representing a business or risk management 
requirement or preference of the smart card issuer. The personalization assistant software (item 
320 in Figure 3) presents queries to the issuer. An example of this is shown in Figure 31. In this 
screen shot, the card issuer is presented with seven queries relating to cardholder verification 
methods (CVM). A user (employee) of the issuer responds to these queries by clicking on a 
"Yes" or "No" button. Figure 32 shows sample smart card features based on the responses to the 
queries presented in Figure 31. For example, for "Manual cash and purchase with cashback 
transactions," a smart card feature is "Signature is required when the device does not support 
Online PIN." For "Purchase without cashback transactions," a smart card feature is "Offline 
Enciphered PIN is used if the device supports it." Other examples of queries presented to the 
issue by the personalization assistant software may be found in Figure 36 ("Making Your Offline 
Data Authentication Risk Management Decisions") and in Figure 38 ("Defining Your Issuer 
Authentication Options"). 

Tushie 

With this description of smart card features and related processes in mind, we now turn 
to the cited references. The primary reference in the §103 rejection is Tushie. Although the 
term "personalization" is used in Tushie, its context is entirely different from the context of the 
claimed invention. The personalization data in Tushie does not relate at all to smart card 
features as determined by a smart card issuer, but rather is directed to basic cardholder data, such 
as name, account number, expiration date, and so on. This type of basic cardholder data plays 
no role in the claimed invention. Basic cardholder data is not " a parameter representing an 
issuer business requirement dictating smart card usage " as required claim 1. 
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Moreover, even if this personalization data was in some manner analogous to the claimed 
"smart card features" (which Applicant denies), its creation by querying a user is not disclosed in 
Tushie. Claim 1 specifically requires: 

providing a user with a plurality of queries regarding said smart card features, 
said queries originating from said software tool; and 

receiving from the user, responses to the plurality of queries, said responses 
being received by said software tool and reflecting smart card features desired by 
said smart card issuer. 

Thus, claim 1 requires determining the smart card features desired by the smart card 
issuer by querying a user. There is no such querying occurring in Tushie. As shown in Figures 
1A and IB of Tushie (and as described in Tushie), the cardholder data is sent from a database 
152 straight to the system 150 and then on to the personalization system 100. This data is not 
modified or generated by queries; it comes unchanged straight from a database. In other words, 
the personalization data is simply transmitted from the card issuer and is not changed or 
modified in any way. (See "Data" from 150 to 100 in Figure 1 A and card holder data moved 
from 152 to 150 to 100 in Figure IB.) There are no queries presented (to any party) or responses 
evaluated in order to create the personalization data (let alone smart card features). Tushie 
focuses on taking raw cardholder personalization data (which is actually basic cardholder data) 
and simply delivering it unchanged to system 100. 

Harms 

Harms is relied on for disclosing the step of providing a user with a plurality of queries 
regarding smart card features. Harms is not related to the claimed invention. Harms relates to 
administering a loyalty programs (or frequent buyer program) by using a government-issued 
card (such as a driver license) instead of a special loyalty card; it has nothing to do with 
personalization of smart cards. (Smart cards are only mentioned once as a future alternative to 
using a driver license.) 

The reference describes how a consumer ("marketing program participant") may key in 
additional data about the consumer, that is, data that may not be stored on the consumer's card. 
The consumer may enter data about a particular transaction, the consumer's opinions, the 
consumer's visits to a particular store, or other information, "as prompted by the prompt queries 
displayed on the identification terminal." "The prompts may also ask for the price and identity 
of the product being purchased, if this information is not otherwise received from the cash 
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register." Harms, Col. 5, lines 17-24. The data collected at the terminal through these queries 
is simply data about the consumer (e.g., driver license number) and is not related or similar to 
the claimed smart card features . The questions prompted in Harms have no relation to the types 
of business and risk management queries a personalization service provider would ask a smart 
card issuer. 

Claim 1 also requires: 

matching each of said responses with an output data value, said matching being 
performed by said software tool, each of said output data values representing one 
of said smart card features and being suitable for personalizing a smart card. 

Thus, each response (representing an answer from a human) is matched with an output 
data value that is suitable for personalizing a smart card. In other words, the output data value is 
a particular identifier, numeral, symbol or other value that is recognizable by a personalization 
machine. Harms does not disclose any such step. 

For these reasons, not only does Harms not disclose the cited steps, it would not have 
been obvious to combine Harms with Tushie because the art is entirely different. Tushie deals 
with trying to make personalization data suitable for any type of smart card personalization 
equipment, while Harms deals with administering a loyalty marketing program. One of skill in 
the art trying to personalizing a smart card would not concern themselves with a loyalty 
marketing program. 

Claim 1 1 includes many of the same limitations as claim 1 and is believed patentable for 
the same reasons. Furthermore, claim 11 includes the step of personalizing the batch of smart 
cards using the personalization data file. This personalization data file includes output data 
values that represent the smart card features desired by the smart card issuer. Because neither 
reference discloses smart card features and their values obtained by querying a user, this step is 
not disclosed. 

Reconsideration of this application and issuance of a Notice of Allowance at an early date 
are respectfully requested. If the Examiner believes a telephone conference would in any way 
expedite prosecution, please do not hesitate to telephone the undersigned at (612) 252-3335. 

Respectfully submitted, 
BEYER LAW GROUP LLP 
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/Jonathan O. Scott/ 



Jonathan O. Scott 
Registration No. 39,364 



P.O. Box 1687 

Cupertino, CA 95015-1687 



Telephone: (612) 252-3330 
Facsimile: (612) 825-6304 
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